Computerized devices control almost every aspect of our life—from writing documents to controlling traffic lights. However, computerized devices are bug-prone, and thus require a testing phase in which the bugs should be discovered. The testing phase is considered one of the most difficult tasks in designing a computerized device. The cost of not discovering a bug may be enormous, as the consequences of the bug may be disastrous. For example, a bug may cause the injury of a person relying on the designated behavior of the computerized device. Additionally, a bug in hardware or firmware may be expensive to fix, as patching it requires call-back of the computerized device. Hence, many developers of computerized devices invest a substantial portion of the development cycle to discover erroneous behaviors of the computerized device.
During a verification phase, developers, QA staff members, verification engineers, and the like test System Under Test (SUT) to verify that a newly developed SUT operates properly. In some cases, test cases (also referred to simply as “tests”) may be devised to provide stimuli to the SUT, and enable testing whether its operation is correct (e.g., as expected).
Verification of hardware systems may include running simulations of the SUT using a simulator or similar platform that is configured to mimic the functionality of the SUT and may be used before the fabrication of the SUT itself. Verification may also be performed in a post-silicon stage.
Test-generation may be used to generate stimuli to be provided the SUT (or simulation thereof), also referred to as a test. The test may include transactions that may be executed in parallel by different components of the SUT and which may be configured to exercise different parts of the SUT.
Tests may be generated by system level test generators. In some exemplary embodiments, a generator may generate a test as an initial step that is followed by a stimulated execution of the test. The test may include stimuli for agents of the system. Optionally, the generator may also create an initial configuration for the components and resources in the system. In some cases, the test generator gets input from a user that directs the generator to wanted scenarios.
The generated tests may have to be valid. Tests may have to be valid not only with respect to the system architectural definition, but also with respect to the input of the user that is using the generator, i.e. in some cases the test should exercise the system in the way that the user specified.